保障微服务应用安全从哪些方面入手

保障微服务应用安全从以下方面入手：

• 身份认证：多数业务功能类的应用的首要任务就是需要做身份认证。对于数据公开或新闻发布类的门户网站类应用不需要考虑这一点，他们更关注的是数据开放之前的管理和审批。身份认证或身份验证，顾名思义就是对应用程序的”访问者”的身份进行验证识别。访问者分两类。基于用户登录的客户端(Login-based Client)：用户访问服务提供者的应用程序的功能时，需要通过一个客户端交互界面来与服务提供者交互，用户需要先登录，然后由客户端代表用户身份去访问服务提供者应用程序。API客户端(API Client)：客户端程序类型的访问者，这类客户端自身具备部分API的访问权限，不需要用户授予其访问权限。

• 访问授权：如果访问者是API客户端时，API调用的权限需由网关进行控制。建议采用先订阅再访问的授权模式，网关应该仅允许API客户端访问其订阅过的API。具体实现方法就是绝大多数网关都会提供的基于APIKey控制API访问的方式。需要注意的是，仅使用APIkey的访问控制是不够的。API Key是在网关订阅API时生成的一串唯一编号，并不具备识别客户端身份的能力。就好比以前买火车票是不实名的，谁拿到火车票，都可以乘坐对应车次。火车票实名制之后，首先需要核验身份证，核验通过后才能购票乘车。如果证票不符，则不允许乘车。将客户端认证和API Key配合进行访问认证和权限校验才是个更安全的方案。

• 通信安全：通信安全的方案就是基于传输过程加密的方式，常见的选择就是使用Https协议通信。微服务架构体系中，逻辑层面上外部请求接入都是通过网关作为入口，网关作为内外网的分界，实际部署上，网关本身也是多实例分布式的高可用部署形态，前面架设有一个负载均衡F5或nginx，用来对外提供Https协议接入和路由转发，而网关内部就是企业内网，默认是可信任的，内网的系统之间的通信会采用更轻量级的HTTP协议。此方案中微服务换成SOA，把网关换成ESB，就是传统的SOA架构中的安全通信方案，本质上没有区别。

• 代码安全：要保证密码不泄露的办法就是做好敏感数据保密，技术手段上则要求存储密码、凭证的地方(配置文件和数据库表)需要加密存储。如：配置文件中的数据库口令、数据表中存放的密码数据等。建议在开发期对于编码规范进行制定，还可以通过工具进行辅助检查和控制，如开源的代码质量管理工具Sonar，可以支持多种程序语言，方便的与编译构建工具集成如Maven，在代码进入正式提交对应分支前就将一些安全问题在前期预防，如SQL注入等。测试阶段，可以通过安全扫描软件，如AppScan等工具对业务系统的前后端功能进行扫描，检查系统漏洞并即时修复。尽量减小在上线运行后出现安全事故的风险。

• 管理审计：运维管理安全方面，根据安全需求，要有安全相关的管理规范和工具支撑，对系统管理、权限分配和关键数据进行严格管控，并做好操作审计日志记录。比如很多安全级别高的行业或企业中如军工类，对于业务系统的修改、权限管理审计做了严格的流程规范和功能支撑。如典型的三员管理，采用三权分立、互相制约的思路，包含系统管理员、安全管理员、安全审计员三个角色，互相能看到对方的信息，将业务过程分成不同的段，每段由对应人员负责，不让任何人掌控全局。审计工作是非常重要的一环，没有任何系统和流程是绝对安全的。关键的操作、数据变化等审计日志需要完整记录。一旦发生问题，可以通过审计日志排查分析追踪。